Skip to content

fix(builder): Skip minify of a .js with an existing -dbg.js sibling - #1659

Open
matz3 wants to merge 1 commit into
mainfrom
fix-minify-dbg-collision
Open

matz3 wants to merge 1 commit into
mainfrom
fix-minify-dbg-collision

Conversation

@matz3

@matz3 matz3 commented Oct 13, 2026

Copy link
Copy Markdown
Member

A -dbg.js next to its .js in the sources is a broken input state: the minify task owns the -dbg.js path and generates it from the .js, so a pre-existing one must not be there. The glob matched both as separate map-step keys. The .js key wrote its generated debug variant to the -dbg.js path, which the -dbg.js key also wrote - two concurrent keys writing one path, which the shared assertDistinctWrite guard rejected, so the build crashed.

To stay robust rather than crash, filter the step keys to skip both members of such a pair: a .js whose -dbg.js sibling already exists is left as it is (that -dbg.js already serves as the debug variant), the -dbg.js is passed through, and a warning is logged. The sibling paths are derived with the shared getDebugName and getNonDebugName helpers, so the special .view.js / .controller.js suffixes are handled consistently.

The integration test reproduces the crash and pins the expected skip; unit tests cover the filter and the warning.

Also add a TODO in the minify processor: a lone -dbg.js (no .js sibling) still reaches the processor and gets a -dbg-dbg.js debug variant, which is almost certainly unintended. Clarify whether such files should be skipped instead.

A -dbg.js next to its .js in the sources is a broken input state: the
minify task owns the -dbg.js path and generates it from the .js, so a
pre-existing one must not be there. The glob matched both as separate
map-step keys. The .js key wrote its generated debug variant to the
-dbg.js path, which the -dbg.js key also wrote - two concurrent keys
writing one path, which the shared assertDistinctWrite guard rejected,
so the build crashed.

To stay robust rather than crash, filter the step keys to skip both
members of such a pair: a .js whose -dbg.js sibling already exists is
left as it is (that -dbg.js already serves as the debug variant), the
-dbg.js is passed through, and a warning is logged. The sibling paths
are derived with the shared getDebugName and getNonDebugName helpers, so
the special .view.js / .controller.js suffixes are handled consistently.

The integration test reproduces the crash and pins the expected skip;
unit tests cover the filter and the warning.

Also add a TODO in the minify processor: a lone -dbg.js (no .js sibling)
still reaches the processor and gets a -dbg-dbg.js debug variant, which
is almost certainly unintended. Clarify whether such files should be
skipped instead.
@matz3
matz3 requested a review from a team October 13, 2026 13:35
@codeworrior

Copy link
Copy Markdown
Member

Maybe I forgot about an earlier decision (e.g. in the wake of the transition from Maven to CLI), but IMO the existence of a *-dbg.js file is not a broken input state. Maybe the capability to deal with it went lost somewhen, but I'm sure we used that in the past, especially for some bootable bundles (for which normally no dbg file is created, but restarting in debug mode required such a file in the past) and for files that our old tooling could not minify at that time (e.g. newer ES6 code).

I searched the SAPUI5 codebase and only found one example in sap.ushell_abap (sap/ushell_abap/thirdparty/sap-xhrlib-esm-dbg.js, an ESM file).

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants